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BACKGROUND OF THE INVENTION 



The present invention relates to modeling architectures for modeling electronic 
systems. More particularly, the present invention relates to architectures for modeling 
1 0 a shared-bus system comprising a plurality of electronic devices interconnected via a 
shared bus. 

One of the more popular ways to interconnect a plurality of electronic devices 
is through the use of a shared bus. For example, a modern computer network employs 
a shared bus, such as a SCSI (Small Computer System Interface) bus, to interconnect 
1 5 the CPU with a plurality of devices such as printers, disk drives, scanners, and the 

like. In a shared bus system, each device on the bus arbitrates for and takes control of 
the bus whenever it needs to communicate with the CPU and/or another device. 

To facilitate discussion, Fig. I shows a simplified illustration of a typical 
shared bus system. In Fig. 1, a shared bus system 1 00 includes a plurality of devices 
20 102, 104, 1 06, and 1 08, which are interconnected via a shared bus 1 1 0. Through bus 
1 10, each device may share its resources with another device by exchanging data and 
commands. 

There are times when it may be useful to model a shared bus system, such as 
shared bus system 100 of Fig. 1 . For example, a hardware or software developer 
25 working on a prototype device may wish to test the prototype device's interaction with 
various devices as well as with the shared bus of a shared bus system. Modeling 
permits the developer to efficiently develop a large number of test cases, each 
representing a particular behavioral scenario for the shared bus devices, with which 
the developer can test the prototype device against. Without modeling, the developer 

ATECP001/SSG-054A 1 PATENT 



would have to physically create a multiplicity of shared bus system configurations and 
configure each real-world shared bus system to obtain the desired behavior against 
which the prototype device can be tested. Modeling allows the developer to 
accomplish the same goal without the expenses and time-consuming efforts of 
5 physically creating a multiplicity of real-world systems for the purpose of testing. 

In the prior art, modeling engineers have typically tried to mimic as faithfully 
as possible each constituent part of the system to be modeled. This approach, termed 
the monolithic modeling approach, attempts to model each constituent device closely 
after its real-world counterpart. That is, the capability and behavior of each device in 

1 0 the system to be modeled are faithfully recreated in software so that when the various 
device models are put together, the assembled modeled system would mimic the 
behavior of its real-world counterpart as faithfully as possible. This modeling 
paradigm is natural since the modeling itself mimics the way the electronic devices 
are packaged and sold by the manufacturer, as well as bought and assembled by the 

15 user, in the real world. 

Fig. 2 illustrates a resultant monolithic system model 200 for the shared bus 
system 100 of Fig. 1. In Fig. 2, there are shown a plurality of device models 202, 204, 
206, and 208 interconnected via a shared bus 216. Each device model includes two 
modules: a logical module and an I/O specific module. The logic module, such as 

20 logic module 202A of device model 202, includes codes and data for modeling 

behaviors that are invariant with respect to the physical interface through which the 
device modeled by device model 202 communicates with the outside world. Thus, in 
a SCSI device, the logic module may contain codes and data for modeling the 
command handler logic, since SCSI commands are standardized irrespective of the 

25 physical interface through which the commands are transmitted. Other logical 

functions such as how to store and address data, how to handle reset, how to respond 
to status if inquired, and configuration of non-I/O specific parameters, etc., are also 
modeled by codes and data in the logical module. The functions performed by the 
reset handler includes, for example, putting the model into a known state as defined 

30 by the SCSI specification following the assertion of SCSI reset on the bus or upon 
initial power-up. The functions of the command handler includes, for example, 
processing the commands received from the initiator (e.g., SCSI host) by, for 
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example, validating the fields of the commands and preparing them for the target to 
process. Configuration of non-I/O specific parameters includes the configuration of 
non-I/O specific parameters that affect how a device behaves (such as, for example, 
sense information, contingent allegiance, mode pages, inquiry data, and the like). 

The I/O specific module, such as I/O specific module 202B of device model 
202, includes codes and data for modeling behaviors that are dependent on the 
physical interface. For example, interfacing functions specific to a given SCSI 
implementation are modeled by codes and data in the I/O specific module. Other 
physical interface-dependent functions and parameters such as the timing information 
(e.g., communication speed, the synchronous or asynchronous nature of the 
communication), I/O specific reset handlers, access methods, configuration of I/O 
specific parameters, and the like, are modeled by codes and data within the I/O 
specific module. The I/O-specific reset handler resets I/O-specific parameters such as, 
for example, asynchronous vs. synchronous, single-ended vs. low voltage differential 
(LVD), narrow vs. wide, single transition vs. dual transition, packetized vs. non- 
packetized, maximum data transfer rate, and the like. Access methods include, for 
example, functions for handling asynchronous or synchronous transfer, packetized, 
data group, SPI-4, and the like. Configuration of I/O specific parameters includes the 
configuration of such I/O-specific parameters as packetized or non-packetized, quick 
arbitration and selection (abbreviated QAS), single transition or dual transition, and 
the like. 

Fig. 2 also shows a timing monitor module 212, representing a module for 
monitoring and validating the timing of the bus cycles. These bus cycles must follow 
specific parameters laid out by the lower level transport mechanism and protocol in 
order for the system as a whole to function correctly. Thus timing monitor module 
212 monitors the devices to assess, for example, whether the devices output data and 
commands in a timely manner and whether they respond in a timely manner. 

A protocol monitor module 214 monitors transactions at a higher protocol 
level. For example, protocol monitor module 214 may monitor such protocol-related 
issues such as data field integrity, transitions between states, the specific SCSI 
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protocol in use, whether the transfer is synchronous or asynchronous, whether the data 
is packetized or not, and whether dual transition is involved, and the like. 

It is observed by the inventor herein, however, that the prior art paradigm of 
modeling a shared bus system by monolithically modeling each constituent device to 
5 faithfully replicate that device's real-world capabilities and behavior and subsequently 
assembling the individual device models and monitor modules into a modeled system 
results in inefficiencies in the configuration and management tasks. To facilitate 
discussion of the shortcomings of the prior art monolithic paradigm, it may be useful 
to briefly discuss the various tasks that need to be handled in the generation of a 
10 typical test case from such a modeled system. 

In order to generate a test case from monolithic system model 200, at least two 
tasks must be performed: 1) configuring the system model 200, and 2) describing the 
actual commands or transactions that take place with the device models. In the first 
task, i.e., configuring the system model 200, a plurality of sub-tasks must be 
15 undertaken. Fig. 3 is a flowchart illustrating the typical sub-tasks required to 

configure a monolithic shared bus system model, such as monolithic system model 
200. 

As shown in Fig. 3, one of the sub-tasks involved in configuring a monolithic 
shared bus system model is specifying parameters for the device models (302). In this 

20 block 302, each device is described to its respective device model. In effect, the sub- 
task in block 302 represents the description of the internal specifications of a device. 
If the device is a disk drive connected to a SCSI bus, for example, these parameters in 
block 302 may include the block size, whether the data is transferred in 8-bit or 16-bit 
chunks, the transfer speed, the CRC (cyclic redundancy check) interval, the 

25 disconnect/reconnect behavior, and the like. These parameters in block 302 may be 
obtained from the manufacturer of each device or may be approximated by a general 
model. 

In block 304, the parameters for connections between devices are specified to 
the connected device models. In this block 304, each device model is configured with 
30 parameters to specify what it can expect when interacting with another device on the 
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shared bus and how it should behave toward that other device. For example, if the 
other device is a slower device, the device being configured may be told to 
communicate only at the maximum speed of the slower device when interacting with 
the slower device. These parameters need to be specified for each possible connection 
between any two device models. 

In block 306, the parameters for the interactions between each device and the 
timing monitor module are specified to the timing monitor module. In this block 306, 
the timing monitor module is configured with parameters to specify what it should 
expect in terms of timing when interacting with each device model. Thus, the 
parameters involved may be, for this example, transfer speed, the specific protocol of 
SCSI in use (since this impacts speed), whether the transfer is synchronous or 
asynchronous, whether the data is packetized or not, and whether dual transition is 
involved. As another example, the timing monitor module may monitor set-up and 
hold time for the various transactions, arbitration time, connect/disconnect time of the 
devices, and the like. These parameters need to be specified for each possible 
connection between a device model and the timing monitor module. 

In block 308, the parameters for interactions between devices are specified to 
the timing monitor module. In block 308, the timing monitor module is configured 
with parameters to specify what it should expect, in terms of timing, when two 
devices interact. This is similar to programming done in block 304, except that in 
block 308, these parameters are specified to the timing monitor module. For example, 
if the one device is a slower device, the timing monitor module may be told to expect 
the other device to communicate only at the maximum speed of the slower device 
when the faster device interacts with the slower device. These parameters need to be 
specified to the timing monitor module for each possible connection between any two 
device models. 

In block 310, the parameters for interactions, at the protocol level, between 
each device and the protocol monitor module are specified to the protocol monitor 
module. In block 310, the protocol monitor module is configured with parameters to 
specify what it should expect, in terms of higher level protocol, when it interacts with 
a device. This is similar to programming done in block 306, except that in block 306, 
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these parameters are specified at the lower level whereas in block 310, the protocol 
monitor module is interested in protocol-related transactions between each device and 
itself. For example, parameters may be configured to tell the protocol monitor module 
what to expect in terms of configuration and data fields, transitions between states, 

5 and the like. Other parameters relevant to protocol integrity issues, such as the 
specific SCSI protocol in use, such as whether the transfer is synchronous or 
asynchronous, whether the data is packetized or not, and whether dual transition is 
involved, and the like, may be specified to the protocol monitor module in block 310 
as well. These parameters need to be specified to the protocol monitor module for 

10 each possible connection between a device model and itself. 

In block 312, the parameters for interactions, at the protocol level, between the 
devices are specified to the protocol monitor module. In block 312, the protocol 
monitor module is configured with parameters to specify what it should expect, in 
terms of higher level protocol, when two devices interact. This is similar to the 
15 programming done in block 308, except that in block 308, these parameters are 
specified at the lower level whereas in block 312, the protocol monitor module is 
interested in protocol-related transactions between two devices. 

As can be appreciated from the discussion above in connection with Fig. 3, the 
prior art monolithic system model involves many configuration steps to configure data 
20 in the various device models as well as in the timing monitor module and in the 
protocol monitoring module. The numerous configuration steps, some of which 
involve provisioning repetitive information in multiple device models and modules, 
disadvantageously increases the management overhead in modeling. 

For example, when there are changes to a device model, the new parameters 
25 for the changed device model need to be specified in order to create the device model 
(block 302) and to properly specify connections between that changed device model 
and other device models (block 304). Some of the same parameters also need to be 
specified to the timing monitor module so the timing monitor module would know 
what to expect regarding that changed device model's behavior toward the timing 
30 monitor module (block 306) or when that changed device model interacts other device 
models (block 308). 
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Further, some of the same parameters also need to be specified to the protocol 
monitor module so the protocol monitor module would know what to expect 
regarding that changed device model's behavior toward the protocol monitor module 
(block 310) or when that changed device model interacts other device models (block 
312). Thus, whenever the parameters for a single device model need to be changed, 
multiple other modules must be reconfigured beside the changed device model. Given 
the fact that the device models may need to be reconfigured hundreds of times in order 
to generate the hundreds of test cases required in a typical verification cycle for a new 
device, the high management overhead associated with the prior art monolithic 
approach to shared bus system modeling disadvantageously renders the task of 
generating the required suite of test cases unnecessarily complex, cumbersome, and 
error-prone. 

Furthermore, the replication of some of the parameters of each device model in 
multiple locations disadvantageously takes up more memory than necessary. 
Additionally, since each device model stores its own parameters, each device model, 
the timing monitor module and the protocol monitor module must, during the 
configuration phase of the modeling software, make function calls to other device 
models in order to obtain the necessary parameters to configure communication 
between itself and each of the other device models. With a large number of device 
models, the total number of function calls can be unduly high and can unduly degrade 
the performance of the modeling software. 

Still further, each device model is implemented, as it is required to do in the 
real world, with its own logic for monitoring, arbitrating, and selecting the shared bus. 
With multiple device models running simultaneously, multiple logic modules for 
performing essentially the same function are executing simultaneously, thereby further 
unnecessarily degrading the performance of the modeling software. 

In view of the foregoing, what is desired is a new architecture for modeling a 
shared bus system that can accurately furnish the desired modeled behavior while 
avoiding the disadvantages associated with the prior art monolithic approach for 
system modeling. 
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SUMMARY OF THE INVENTION 



The invention relates, in one embodiment, to a software-implemented shared 
bus system model for modeling a shared bus system that includes a plurality of 
5 devices interconnected via a shared bus. The system model includes a first device 
model for partially modeling a first one of the plurality of devices, the first device 
model including a first modified logical module and a first modified I/O-specific 
module. The system model further includes a sharable module having provisioned 
therein first shareable data. The first shareable data is shareable by the first device 

10 model and another device model of the plurality of device models. The first shareable 
data represents I/O-specific data associated with the first device model that is also 
needed by the another device model of the plurality of device models during 
configuration of the shared bus system model. The first shareable data further 
represents data that would have been provisioned within the first device model if the 

15 first device model had been configured to closely mimic the data content of the first 
one of the plurality of devices, the first shareable data instead being provisioned in the 
shareable module. 

In another embodiment, the invention relates to a software-implemented 
method for creating a shared bus system model. The shared bus system model is 

20 configured to model a shared bus system comprising a shared bus and a set of devices 
coupled to the shared bus. The shared bus system model includes a set of device 
models, each of the set of device models partially models a respective one of the set of 
devices. The shared bus system model further includes a monitoring module that 
monitors bus behavior of individual ones of the set of device models, and a shareable 

25 module that is communicable with the set of device-specific models and the 

monitoring module. The computer-implemented method includes providing first non- 
I/O specific data to a first device model of the set of device models. The computer- 
implemented method further includes providing first shareable data to the shareable 
module. The first shareable data is associated with the first device. The first 

30 shareable data represents I/O-specific data associated with the first device model that 
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is also needed by the another device model of the plurality of device models during 
configuration of the shared bus system model. The first shareable data further 
represents data that would have been provisioned within the first device model if the 
first device model had been configured to closely mimic the data content of the first 
5 one of the plurality of devices, the first shareable data instead being provisioned in the 
shareable module, wherein both the monitoring module and the first device model 
employ the first shareable data to configure, during configuration of the shared bus 
system model, the monitoring module and the first device model to appropriately 
model the shared bus system during execution. 

10 These and other features of the present invention will be described in more 

detail below in the detailed description of the invention and in conjunction with the 
following figures. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



The present invention is illustrated by way of example, and not by way of 
limitation, in the figures of the accompanying drawings and in which like reference 
numerals refer to similar elements and in which: 

To facilitate discussion, Fig. 1 shows a simplified illustration of a typical 
shared bus system 

Fig. 2 illustrates a prior art monolithic system model for the shared bus system 
of Fig. 1. 

Fig. 3 is a flowchart illustrating the typical sub-tasks required to configure a 
monolithic shared bus system model. 

Fig. 4 illustrates, in accordance with one aspect of the present invention, an 
architecture for the improved shared bus system model. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



The present invention will now be described in detail with reference to a few 
preferred embodiments thereof as illustrated in the accompanying drawings. In the 
following description, numerous specific details are set forth in order to provide a 
thorough understanding of the present invention. It will be apparent, however, to one 
skilled in the art, that the present invention may be practiced without some or all of 
these specific details. In other instances, well known process steps and/or structures 
have not been described in detail in order to not unnecessarily obscure the present 
invention. 

In accordance with one aspect of the present invention, there is provided an 
improved architecture for modeling shared bus systems. It is realized by the inventor 
herein that from a functional perspective, it is unnecessary and even undesirable to 
attempt to exactly duplicate the capabilities and data content of each real-life device in 
each device model of the system model. As long as the system model as a whole, 
when viewed from the perspective of the prototype device, can provide the 
appropriate responses when interacting with the prototype device, the system model 
would have fulfilled its required role. 

Take for example the SCSI device selection procedure. When the prototype 
device wishes to select another device for communication, it asserts in turn a "BUSY" 
signal and a "SELECT" signal on the shared bus. In the real world, each device on the 
shared bus would monitor the shared bus to ascertain whether its own ID is present on 
the shared bus. If a device detects that its own ID was issued, it responds, thereby 
completing the selection process and facilitating the commencement of data exchange. 

In the model world, as far as the prototype device is concerned, it is irrelevant 
whether each device model monitors for the asserted "BUSY" signal and "SELECT" 
signal and for its own ID, or whether this function is performed by a single shared 
logic module on behalf of all device models. As long as the device model is informed 
that it is selected so it can begin communication, it is irrelevant to the prototype 
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device whether the monitoring of that selection signal is performed by each device 
model or by one shared module. 

As another example, it is unnecessary and even undesirable to replicate some 
of the parameters pertaining to a device model among multiple modules. From the 
5 prototype model perspective, it is irrelevant where the parameters reside. As long as 
the various device models, the timing monitor module, and the protocol monitor 
module can access the parameters and configure themselves to interact appropriately 
with the prototype device during execution, the system model would have fulfilled its 
requisite role. 

1 0 Thus, in accordance with one aspect of the present invention, there is provided 

an inventive shared bus system model and method therefor in which some of the 
parameters and logic functions that normally would have been provisioned within the 
individual device models, if the individual device models had been faithfully 
patterned after their real-world counterparts, are instead provided to a shareable 

15 module. The shareable module is accessible by the other device models and the 
monitoring modules (such as the timing monitor module and the protocol monitor 
module in the SCSI example). Within the shareable module, a data structure stores 
shareable device-specific parameters associated with the device models. In general, 
these device-specific parameters stored in the data structure of the shareable module 

20 pertain to interface-specific parameters 

The shareable device-specific parameters are associated in the data structure 
with their respective device model IDs. In this manner, the shareable device-specific 
parameters of each device model are stored in a single location, thereby reducing 
replication of data and unnecessary function calls, yet accessible to all other device 
25 models and monitoring modules for their use. Although this arrangement does not 
faithfully reproduce the real-world capabilities and data content of the individual 
devices, the system model created in accordance with this paradigm, as a whole, 
appears to a prototype device substantially similar to a shared bus with a plurality of 
devices coupled thereto and thus can be employed as any shared bus system model. 
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Furthermore, in accordance with one aspect of the present invention, some of 
the shareable logic functions normally performed by the real-world devices are 
performed instead by codes in the shareable module. As the term is employed herein, 
a shareable logic function is a logic function that is performed in more than one device 
5 model. Monitoring the shared bus for selection, as discussed above, is one such 

shareable function. Thus, in accordance with this aspect of the present invention, the 
device models that represent the real-world devices are not provisioned with codes 
that perform some of the requisite but shareable logic functions. Instead, the 
shareable codes in the shareable module perform the requisite shareable logic function 

1 0 and pass information to the relevant device model to enable that relevant device 

model to respond. Again, although this arrangement does not faithfully reproduce the 
real-world capabilities of the individual devices, the system model created in 
accordance with this paradigm, as a whole, appears to a prototype substantially similar 
to a shared bus with a plurality of devices coupled thereto and thus can be employed 

15 as any shared bus system model. 

By grouping shareable parameters and shareable logic functions and managing 
them in a single location, the invention advantageously avoids the high management 
overhead of the prior art monolithic modeling paradigm. Further, since the shareable 
parameters pertaining to the device models do not need to be replicated among 
20 different modules, less memory is required and execution speed is improved. The fact 
that some of the shareable logic functions are performed by a single entity (i.e., the 
shareable module) also reduces the CPU cycles required to execute these logic 
functions on behalf of the various device models. 

The invention may be better understood with reference to Fig. 4 that follows. 

25 In Fig. 4, there are shown a plurality of device models 402, 404, 406, and 408, 
representing device models for partially modeling their real-world devices. The 
devices models of Fig. 4 only partially model their real-world devices since, as will be 
discussed later herein, the shareable parameters and shareable logic functions of the 
devices are provisioned in a data structure in a shareable module instead of being 

30 provisioned with the respective device models. 
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Each device model includes two modules: a modified logical module and a 
modified I/O specific module. The modified logical module (such as modified logical 
module 402A of device model 402) includes codes and data for modeling behaviors 
that are invariant with respect to the physical interface. The modified logic modules 
5 and modified I/O specific modules are regarded as "modified" since some of the logic 
codes and data, to the extent they are also required in other device models, are 
provisioned in the shareable module 412. Thus, the modified logical module of a 
device model preferably includes only codes and data specific to requirements of that 
device model. That is, logic codes and data that are in common with other device 

1 0 models or that are required by other device models for configuration and/or execution 
are preferably provisioned in shareable module 412 instead. Furthermore, it is 
preferable that the shareable logic codes, to the extent they are provisioned in 
shareable module 412, not be replicated in the device models. In this manner, the 
shareable logic codes may execute on behalf of all device models or a plurality of 

15 device models, substantially reducing the CPU cycles required to perform these 
logical functions. 

For example, the modified logical module may include, to the extent they are 
non-I/O specific, reset handlers, command handlers, and configuration of non-EO- 
specific parameters. The functions performed by the reset handler of the modified 

20 logical module includes, for example, the non-I/O specific reset tasks pertaining to 
putting the model into a known state as defined by the SCSI specification following 
the assertion of SCSI reset on the bus or upon initial power up. The functions of the 
command handler includes, for example, the non-I/O specific reset tasks pertaining to 
processing the commands received from the initiator (e.g., SCSI host) by, for 

25 example, validating the fields of the commands and preparing them for the target to 
process. Configuration of non-I/O specific parameters includes the configuration of 
non-I/O specific parameters that affect how a device behaves (such as, for example, 
sense information, contingent allegiance, mode pages, inquiry data, and the like). 

Each device model may also include a modified I/O specific module. The 
30 modified I/O specific module (such as modified I/O specific module 402B of device 
model 402) includes codes and data for modeling behaviors that are dependent on the 
physical interface. However, unlike the I/O specific module of the prior art 
ATECP00 1/SSG-054A 14 PATENT 



monolithically device models (such as I/O specific module 202B of prior art device 
model 202), the modified I/O specific module 402B of the present invention 
preferably only includes codes and data specific to the requirements of its respective 
device model. Thus, in some (but not necessarily all) device models, there may not 
even be a need for a modified I/O specific module. That is, data (including device 
parameters) common to the shared bus and/or other device models are preferably 
provisioned in the database in shared module 412 instead. By way of example, the 
modified I/O specific module may include functions to configure I/O specific 
parameters and interface (such as APIs or other types of programming interfaces) to 
shared low level (e.g., I/O-specific) routines provisioned in the shareable module. 

Furthermore, it is preferable that the shareable data/parameters, to the extent 
they are provisioned in shareable module 412, not be replicated in the device models. 
In this manner, the shareable data portion pertaining to the device models are 
centralized in shared module 412, substantially reducing the overhead involved in 
maintaining or updating such data. In general, the shareable module may include data 
and functions that may be utilized by more than one device model and/or monitor 
module. The data and functions provisioned within the shareable module may 
include, for example, I/O specific reset handlers, timing information, access methods, 
configuration of I/O specific parameters, timing monitors, protocol monitors, interface 
to higher level routines, and the like. Some of these functions and parameters perform 
substantially the same functions as those performed by their individual counterparts 
that are provisioned in the prior art device models. The interface to higher level 
routines include APIs or other programming interfaces for communicating with non- 
I/O specific routines. However, these I/O-specific data and functions are now, to the 
extent practicable, preferably centralized in the shareable module. 

Further, I/O codes common to the shared bus and/or other device models are 
preferably provisioned in the shareable module 412 instead. Again, it is preferable 
that the shareable I/O codes, to the extent they are provisioned in shareable module 
412, not be replicated in the device models. 

Thus the inventive modeling paradigm does not seek to exactly mimic the 
capabilities and data content of the individual devices with the device models. 
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Instead, a system-level view is taken, and the functions required of the modeled 
system as a whole, from the perspective of a prototype device interacting with the 
modeled system, are handled in the shareable module, the timing monitor module, the 
protocol module, and the individual device models. 

5 One skilled in the art will readily recognize that some judgment may be 

exercised with respect to the amount of shareable codes and data to be provisioned in 
the shareable module 412. In general, if codes or data/parameters can be used by 
multiple devices and/or modules, they are eligible to be provisioned in the shareable 
module instead to reduce memory space utilization, CPU cycle time during 

10 configuration, execution, and/or overhead during maintenance/update. Further, some 
judgment may be exercised with regard to whether the shareable codes or 
data/parameters pertaining to a given device model, once provisioned within the 
shareable module, should be replicated in that device model. In some cases, the 
availability of local codes and/or data/parameters may help the device model to 

15 execute faster, in some cases enough to offset the increased memory utilization. Since 
the shareable codes and/or data/parameters are also available in the shareable module 
for other device models and modules (such as the timing monitor module or the 
protocol monitor module) to access and use already, the amount of overhead is already 
reduced since they do not need to be provided to all other devices and modules. 

20 In Fig. 4, there is also shown a timing monitor module 414 and a protocol 

monitor module 416. In one embodiment, timing monitor module 414 and a protocol 
monitor module 416 are logic functions provided within the shareable module itself. 
The timing monitor module 414 and protocol monitor module 416 performs timing 
validation of bus cycles and monitoring for protocol compliance as discussed earlier. 

25 However, since they have access to the shareable codes and data/parameters in 

shareable module 412, they do not have to be configured with each device model's 
parameters as was required in the prior art. 

In one embodiment, the timing monitor module 414 is provisioned with 
processing logic to determine, from a device model's shareable parameters that are 
30 stored in the shareable module 412, the expected timing behavior when that device 
model interacts with timing monitor module 414. Further, timing monitor module 
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414 is preferably provisioned with processing logic to determine, from the shareable 
parameters associated with any two device models, what their expected timing 
behavior should be with respect to one another when they interact. If necessary, the 
timing monitor module may make a call to the device model to obtain any needed 
5 data/parameters. However, the number of times such calls need to be made will be 
fewer with the inventive modeling architecture since some or most of the shareable 
data/parameters are available in the shareable module. 

Likewise, in one embodiment, the protocol monitor module 416 is provisioned 
with processing logic to determine, from a device model's shareable parameters that 

10 are stored in the shareable module 412, the expected protocol behavior when that 

device model interacts with protocol monitor module 416. Further, protocol monitor 
module 414 is preferably provisioned with processing logic to determine, from the 
shareable parameters associated with any two device models, what their expected 
protocol behavior should be with respect to one another when they interact. If 

15 necessary, the protocol monitor module may make a call to the device model to obtain 
any needed data/parameters. However, the number of times such calls need to be 
made will be fewer with the inventive modeling architecture since some or most of the 
shareable data/parameters are available in the shareable module. 

In Fig. 4, device models 402, 404, 406, and 408 are shown adjacent to 
20 shareable module 412 to highlight the fact that these device models may directly 

access the parameters and functions provisioned within shareable module 412. In the 
implementation of Fig. 4, the timing monitor module 414 and the protocol monitor 
module 416 are shown to be part of shareable module 412 to highlight the fact that 
functionally, these monitor modules are utilized by and interact with all device models 
25 and thus may be thought of as a shareable resource. Fig. 4 also shows a shared bus 
418, representing the shared bus through which a prototype device may interact with 
the various device models of Fig. 4, as well as with the timing monitor 414 and the 
protocol monitor 416, and with bus 418 itself. 

Thus, when parameters associated with a device model needs to be updated, 
30 they only need to be configured in shareable module 4 1 2 and, to the extent they are 
not provisioned within shareable module 412, in that device model itself. AH other 
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device models, timing monitor module 414, and protocol monitor module 416 all 
access the shareable parameters and can process the shareable parameters to configure 
themselves and/or to know the expected behavior when the newly updated device 
model communicates on the shared bus. There is less of a need to update the changed 
5 parameters (or a subset thereof) in multiple device models, the timing monitor 
module, and the protocol monitor module in the manner required in the prior art 
monolithic system model. 

To better illustrate the inventive modeling architecture, some examples are 
provided in Tables 1-4. Table 1 illustrates, in one implementation of the prior art 
10 modeling architecture, the parameters and/or logic functions provisioned in the logic 
module and I/O specific module of each device model in a generic shared bus system 
model. 
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Table 1 

Prior Art (Generic 
shared bus 
implementation) 

Logic Module 


Exemplar}' Parameters And/Or Logic Functions Provisioned 

1 . Reset Handler. 

2. Command Handlers. 

3. Configuration of non-I/O specific parameters. 


Table 1 

Prior Art (Generic 
shared bus 
implementation) 

I/O Specific Module 


Exemplary Parameters And/Or Logic Functions Provisioned 

1 . I/O Specific Reset Handler. 

2. Timing information. 

3. Access methods. 

4. Configuration of I/O specific parameters. 



Table 1 : Exemplary Prior Art Modeling Architecture For A Generic Shared Bus 
System 
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In contrast to Table 1, Table 2 illustrates, in accordance with one embodiment 
of the inventive shared bus system modeling architecture for a generic shared bus, the 
parameters and/or logic functions provisioned in the modified logic module and 
modified I/O specific module of each device model as well as the parameters and/or 
logic functions provisioned in the shared module. 



Table 2 

Invention (Generic 
shared bus 
implementation) 

Modified Logic 
module 


Exemplary Parameters And/Or Logic Functions Provisioned 

1 . Reset Handler. 

2. Command Handlers. 

3. Configuration of non-I/O specific parameters. 


Table 2 

Invention (Generic 
shared bus 
implementation) 

Modified I/O Specific 
Module 


Exemplary Parameters And/Or Logic Functions Provisioned 

1 . Interface to shared low level routines. 

2. Configuration of I/O specific parameters. 


Table 2 

Invention (Generic 
shared bus 
implementation) 

Shareable Module 


Exemplary Parameters And/Or Logic Functions Provisioned 

1 . I/O Specific Reset Handler. 

2. Timing information. 

3. Access methods. 

4. Configuration of I/O specific parameters. 

5. Timing monitors. 

6. Protocol monitors. 

7. Interface to higher level routines. 



Table 2: Exemplary Implementation Of Inventive Modeling Architecture For A 
Generic Shared Bus System 



ATECP001/SSG-054A 



20 



PATENT 



Table 3 illustrates, in one implementation of the prior art modeling 
architecture, the parameters and/or logic functions provisioned in the logic module 
and I/O specific module of each device model in a SCSI-based system model. 



Table 3 


Exemplary Parameters And/Or Logic Functions Provisioned 


Prior Art (SCSI 




implementation) 


1. set own id 




2. get own id 


Logic Module 


3. set block size 




4. get block size 




5. set_data 








7 set _ persistent data len<mh 




8. get persistent data length 




9. set buffer 




10. get buffer 




11. set_inquiry_size 




12. get__incjuiry size 




13. set inquiry 




14. get_inquiry 




1 5 . set buffer size 




16. get buffer size 




17. set echo buffer size 




18. get echo buffer size 




19. set_maximum_lun 




20. get maximum lun 




21. set_all_unit_attention 




22. set_unit_attention_for_lun 




23. get_unit attention 




24. set_all_sense_key 




25. set sense key for lun 




26. get sense key 




27. set_unit_attention_at__reset 




28. get unit attention at reset 








30. get_TAS 




3 1 . reset_handler 




32. add_str 




33. command_handler 


Table 3 


34. configure_standalone_str 


Prior Art (SCSI 


35. inquiry_handler 


implementation) 


36. read_handler 




37. read_buffer_hand!er 


Logic Module 


38. request_sense_handler 


(continued) 


39. test unit ready handler 
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40. write_handler 




41. write_buffer_handler 




42. set sense data 


Table 3 


Exemplary Parameters And/Or Logic Functions Provisioned 


Prior Art (SCSI 






implementation) 


1 . 


set_capabilities 


I/O Specific Module 


2. 
3. 


get_capabilities 
update_inquiry_data 




4> 


set_spi4_assertion_qualifies 4 bytes 




5. 


get_spi4_assertion_qualifies_4_bytes 




6. 


configure_standalone_str 




7. 
8. 


bus_free 
disconnect 




9. 


message_reject 




10 
1 1 


send_ignore_wide residue 
receive_command 




12 


receive_message 




13 


send_message 




14 


send_status 




15 


async_send 




16 


async_receive 




17 
18 


manual_async_send 
manual_async_receive 




19 


manual_sync_send_data 




20 


manual_sync_receive data 




21. manual_data_group_send 




22. manual_data_group_receive 




23. manual_packet_send 




24. manual_packet_receive 




25. manual_spi4_packet send 




26. manual_spi4_packet_receive 




27. execute_manual_phases 




28. compare_bytes 


Table 


29 


compare_words 


Prior Art f^P^T 


30 


compare_bits 


implementation) 


31. 


req_assert 




32. 


update_ack_count 


yj\j opeuuiu lviuuuie 


33. 


ack_assert_monitor 


(Continued) 


34. 


get_st_data 




35. 


put_st_data 




36. 


reqjoggle 




37. 


ack_toggle_monitor 




38. 


dt_receive_acks 




39. 


get_dt_data 




40. 


put_dt_data 




41. 


get dt pad crc 
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42. req_dt_pad crc 




43. send_pad crc 




44. abort task 




45. abort task set 




46. abort it nexus 




47. clear_task set 




48. reset_Iogical_unit 




49. setup timing 




50. receive data 




5 1 . send data 




52. async send data 




53. async receive data 




54. sync send data 




55. sync_receive data 




56. send_data_group 




57. receive_data group 




58. spi4 send data group 




59. send packet 




60. receive packet 




61.spi4_send packet 




62. spi4 receive packet 




63. send data packet 




64. receive data packet 




65. receive_data stream 




66. spi4 send data packet 




67. spi4_receive_data_packet 




68. spi4_send_data_stream 




69. spi4 receive data stream 




70. wait for selection 




71. do reselect 


Tabte 




Prior Art fSPST 


/ z. do disconnect 


implementation) 


73. get command 




74. receive_lq packet 


I/O Specific Module 


75. send_lq_packet 


(Continued) 


76. receive_packetized_commands 




77. receive_command packet 




78. automatic_execution handler 




79. reset_handler 




80. message_handler 




81. extended message handler 




82. event handler 




83. execute command 




84. process command 




85. command_complete 




86. initiate_qas 




87. set_xfer_params 




88. get xfer params 
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89. set_width 




90. set fairness 




91. get_fairness 




92. set crc wait 




93. get crc wait 




94. set send ignore wide residue message 




95 crpt •nPTiH icxnnrp wiHp rpciHnp mpcccirrf* 
y ~> • g^i_ociiu_igiiuic_wiuc_i cbiuuc iiicsoagc 




96. set training out information valid 




97. set data in skew 




98. set_skew_data 




99. set lvd 




1 nO rrct ii/A 

luu. get ivu 




1 U 1 . 5C L W lull i 




102. get width 




103. set_data_in_skew 




104. get_data_in_skew 




105. set_data out skew 




106. get data out skew 




107. set_xfer_params 




108. assert bsy 




109. assert sel 




110. assert atn 




111. assert req 




112. assert_ack 




113. assert cd 




114. assert msg 




115. assert io 




116. assert reset 


Table 3 


1 1 7. assert P CRCA 


Prior Art (SCSI 


118. assert_Pl 


implementation) 


119. negate_bsy 




120. negate_sel 


I/O Specific Module 


121. negate_atn 


(Continued) 


122. negate req 




123. negate ack 




124. negate cd 




125. negate msg 




126. ne°ate io 








1 95? npcratp P PR PA 




129. negate PI 




130. release bsy 




131. release sel 




132. release atn 




133. release_req 




134. release_ack 




135. release_cd 




136. release msg 
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1^8 


release io 




lis. 


release_reset 




139. 


release_P_CRCA 




140. 


release_Pl 




141. 


toggle_ack 






togglejreq 




143. 


toggle_P 1 




144. 






145. 


drive data 






d ri ve_low_d ata 




147. 


drive_high_data 




148. 


release data 




149. 


negate data 




150 


release data bus 




151. 






152. 


assert_data_bit 




153. 


release_data bit 




154 


get low data byte 




155 


get high data byte 




156 


get data 


Table 3 


157. 




Prior Art (SCSI 


158. 


get PI 


implementation) 


159. 


& et_atn 




160. 


get reset 


I/O Specific rvlodule 


161. 


drive_low_data and parity 


(Continued) 


162 


drive_high_data_and_parity 




163. 


drive_data and parity 




164. 


drive aed 




165. 


check_low_parity 






check_high_parity 




167 


check both parity 




168. 


check_data bus_for_x 




169. 


drive rec] desReweu 




170. 


drive ack deskewed 




171. 


drive data deskewed bit 




172. 


drive_p_crca deskewed 




173. 


drive_pl deskewed 




174. 


drive_low_parity 




175. 


drive_high_parity 




176. 


drive reset 






drive attention 




178* 


arb itrate 




179. 






180. 


check_fairness 




181. 


get_arbitration_winner 




182. 


get_target_id 




183. 


bsy is asserted 
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184. 


sel_is_asserted 




185. 


reset_is_asserted 




186. 


cd_is_asserted 




187. 


io_is_asserted 




188. 


msg_is_asserted 




189. 


atn_is_asserted 




190. 


req_is_asserted 




191. 


ack_is_asserted 




192. 


P_CRCA_is_asserted 




193. 


deskewed_P_CRCA_is_asserted 






PI is asserted 




195 


PI is negated 




196. 
— — — 


bsy is deasserted 


Tab l e 




. — ■ — 

sel is deasserted 




198. 


atn is deasserted 


implementation) 


199. 


reset_is_deasserted 




™?' 


number_of_data_bits_on 


I/O Speciiic Module 


201. 


is_phase 


(Continued) 


202. 


check_phase 




203. 


set_phase 




204. 


torce_phase 






get_phase 




906 


target bus free 




9f)7 


initiator_bus_free 






reselect 




209. 


selection_response 




210. 


reselection response 




211. 


select 




212. 


reset_scsi_bus 




213. 


validate_aed 




o!c' 


wait_for ack 




215. 


wait for not ack 




216. 


wait_for_ack_posedge 




217. 


wait_fo r_ack_neged ge 




218. 


wait_for_ack_deskewed_posedge 




219. 


wait_for ack deskewed negedge 




220. 


wait_for_ack_change 




221. 


wait_for_req 




222. 


wait_for_not_req 




223. 


wait_for_req_posedge 




224. 


wait for req negedge 




225. 


wait_for_req_deskewed posedge 






wait_for req deskewed negedge 




227. 


wait_for_req_change 




228. 


wait_for_req_deskewed_change 




229. 


wait_for_sel 




230. 


wait for not sel 
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231. 


wait for bsy 




232. 


wait_for_not_bsy 




233. 


wait_for_bus_free 




234 


wait_for_data 




235. 


Weill LOT .r rvl_/v 




236. 


wait for not P CRCA 


Table 3 


237. 


wait for PI ~ 


Prior Art (SCSI 


238. 


wait for not PI 


implementation) 


239. 


protocol_monitor 




240. 


ous^_pnase monitor 


I/O Specific Module 


241. 


enable bus phase monitor 


(Continued) 


242. 


bus exception monitor 




243. 


rst monitor 




244. 


bsy monitor 




245. 


sel monitor 




246. 


req monitor 




247. 


aclc monitor 




248. 


cd_monitor 




249. 


10 monitor 




250. 






251. 


atn monitor 




252. 


data bit monitor 




253. 


data out monitor 




254. 


data in monitor 




255. 


wait for phase change 




256. 


wait for req_or phase change 




257. 


wait for control change 




258. 


wait for data change 




259. 


wait for parity change 




260. 


wait for data or parity change 




261. 


wait for any change 




262. 


check min timing 




263. 


check max timing 




264. 


hii^ frpp cfatp 
uu:> ii cc alaic 




265. 


reset state 




266. 


arbitration state 




267. 


cjas_arbitration state 




268. 


selection state 




269. 






270. 


iiitcsoagc ill Male 




271. 






272. 


statu s_state 




273. 


st data in state 




274. 


st_data_out_state 




275. 


dt_data_in_state 




276. 


dt_data_out_state 


Table 3 


277. 


spi4 dt data in state 
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Prior Art (SCSI 


278. 


spi4_dt_data_out_state 


implementation) 


279. 


indeterm inate_state 




280. 


add_device 


I/O Specific Module 


281. 


remove_device 


(Continued) 


282. 


add_event 




283. 


broadcast_event 




284. 


check_data_deskewed_assert 




285. 


check_P_CRCA_deskewed_assert 




286. 


check_P l_deskewed_assert 




287. 


check_data_P_CRCA_deskewed_assert 




288. 


check_data_P 1 _deskewed_assert 




289. 


check_data_P_CRCAJPl_deskewed_assert 




290. 


check_data_deskewed_negate 




291. 


check_P_CRCA_deskewed_negate 




292. 


check_P 1 _deskewed_negate 




293. 


check_data_P_CRCA_deskewed_negate 




294. 


check data_Pl_deskewed_negate 




295. 


check_data_P_CRC A_P 1 _deskewed_negate 




296. 


spi4_data_in_monitor 




297. 


spi4 data_out_monitor 




298. 


spi4_training_pattern_in_monitor 




299. 


spi4_training_pattern_out_monitor 




300. 


frc_ack_monitor 




301. 


frc_req_monitor 




302. 


wait_for_data_in_training_done 




303. 


wait_for_data_out_training_done 




304. 


wait for target data out training done 




305. 


spi_wait_for_dt_data_in 




306. 


sp i_wait_for_dt_data_out 




307. 


spi get data 



Table 3: Exemplary Prior Art Modeling Architecture For A SCSI-Based System 
Model 
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In contrast to Table 3, Table 4 illustrates, in accordance with one embodiment 
of the inventive shared bus system modeling architecture for a SCSI-based system 
model, the parameters and/or logic functions provisioned in the modified logic 
module and modified I/O specific module of each device model as well as the 
parameters and/or logic functions provisioned in the shared module. 



Table 4 


Exemplary Parameters And/Or Logic Functions Provisioned 


Invention (SCSI 






implementation) 








1. 


set_own_id 


Modified Logic 


2. 


get_own_id 


Module 


3. 


set_block_size 




4. 


get_block_size 




5. 


set_data 




6. 


get data 




7. 


set_persistent_data_length 




8. 


get_persistent_data_length 




9. 


set_buffer 




10. 


get_buffer 




11. 


set_inquiry_size 




12. 


get_inquiry_size 




13. 


setjnquiry 




14. 


get_inquiry 




15. 


set_buffer_size 




16. 


get_buffer_size 




17. 


set_echo_buffer_size 




18. 


get echo_buffer_size 




19. 


set_maximum_lun 




20. 


get maximum_lun 




21. 


set_all_unit_attention 




22. 


set_un it_attention_for_lun 




23. 


get_unit_attention 




24. 


set_all_sense_key 




25. 


set_sense_key_for_l un 


Table 4 


26. 


get_sense_key 


Invention (SCSI 


27. 


set_unit_attention_at_reset 


implementation) 


28. 


get_unit_attention_at_reset 




29. 


set_TAS 


Modified Logic 


30. 


getJTAS 


Module 


31. 


reset_handler 


(Continued) 


32. 


add_str 




33. 


commandjiandler 




34. 


configure_standalone_str 




35. 


inquiry_handler 




36. 


read handler 



ATECP001/SSG-054A 



29 



PATENT 





37. read buffer handler 




38. request sense handler 




39. test_unit_ready_handler 




40. write handler 




41. write buffer handler 




42. set sense data 


Table 4 


i_^A.viii^iai_y i aiauicLcii r\iiu/wi juugic jruncuons Jrrovisioneo 


Invention (SCSI 


implementation) 


1. set capabilities 




2. get capabilities 


Modified I/O Specific 


3. update inquiry data 


Module 


4. set_spi4 assertion qualifies 4 bytes 




5. get_spi4_assertion qualifies 4 bytes 




6. configure standalone str 




7. bus_free 




8. disconnect 




9. message reject 




10. send ignore wide residue 




1 1 . receive_command 




12. receive_message 




13. send message 




1 4. send status 




15. async send 




16. async receive 




17. manual async send 




18. manual_async_receive 




19. manual_sync_send_data 




20. manual_sync_receive_data 




2 1 . manual_data_group_send 




22. manual_data_group_receive 




23. manual_packet_send 




24. manual_packet_receive 


Table 4 


25. manual spi4 packet send 


Invention (SCSI 


26. manual spi4 packet receive 


implementation) 


27. execute manual phases 




28. compare bytes 


Modified I/O Specific 


29. compare words 


Module 


30. compare bits 


(continued) 


3 1 . req assert 




32. update_ack_count 




33. ack assert monitor 




34. get st data 




35. put st data 




36. req toggle 




37. ack_toggle_monitor 




38. dt_receive_acks 




39. get_dt_data 




40. put dt data 
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4 1 . get_dt_pad_crc 




42. req_dt_pad_crc 




43. send pad crc 




44. abort task 




45 abort task set 




46. abort it nexus 




47. clear task set 




49 setu^'^min ~ Unit 








50 receiv "d't 8 
. receive a a 




j i . send data 




52. async send data 




53. async receive data 




54. sync send data 




55. sync receive data 




56. send data group 




57. receive data group 




5 8 spi4 send data group 




59. send packet 




60. receive packet 








62. spi4 receive packet 




63. send data packet 




64. receive data packet 




65. receive data stream 


Table 4 




invention ^j>l.m 


do. spi4 send data packet 


implementation) 


Vq sp ^- rece ' v ^-^ ata - packet 




do. spi4 send data stream 


Modified I/O Specific 


69. spi4 receive data stream 


Module 


70. wait for selection 


(continued) 


71. do reselect 




72. do disconnect 




73. get command 




74. receive lc| packet 




75. send lq packet 




76. receive packetized commands 




77. receive command packet 




78. automatic execution handler 




79. reset handler 




80. message handler 




81. extended message handler 




82. event handler 




83. execute command 




84. process command 




85. command_complete 




86. initiate_qas 




87. set_xfer_params 




88. get xfer params 
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89. set_width 

90. set_fairness 

9 1 . get_fairness 

92. set_crc_wait 

93 . get_crc_wait 

94. set_send_ignore_wide_residue_message 

95. get_send_ignore_wide_residue message 

96. set_training_out_information_valid 

97. set_data in skew 
98 set skew data 


Table 4 


— - — 

Exemplary Parameters And/Or Logic Functions Provisioned 


Invention (SCSI 


implementation) 


1 set Ivd 




Z. gel 1VU 


Shareable Module 
a e o u e 


3. set_width 




4. get width 




5. set data in skew 




6. get data in skew 




7. set data out skew 




8. get data out skew 




9. set xfer params 




10. assert bsy 




1 1 . assert sel 




12. assert atn 




asse ^- re( 3 




14. assert ack 




15. assert cd 




16. assert_msg 




1 7. assert io 




18. assert reset 




iy. assert_r lkla 




20. assert PI 








22. negate sel 




23. negate atn 




24. negate req 




2 5 negate ack 




26. negate cd 




27. negate_msg 




28. negate_io 




29. negate_reset 




30. negate P CRCA 




3 1 . negate PI 




32. release bsy 




33. release_sel 




34. release_atn 




35. release_req 




36. release ack 
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37. release cd 




38. releasejnsg 




39. release_io 




40. release_reset 


Table 4 


41. release_P_CRCA 


Tnvpntinn fQf^QT 

invcnLiun ^ov,oi 


42. release PI 


implementation) 


43. toggle ack 




44. toggle_req 


Shareable Module 


45.toggle_Pl 


(Continued) 


46. is lvd 




47. drive_data 




48. drive_low_data 




49. drive high data 




50. release data 




51. negate data 




52. release data bus 




53. drive data bit 




54. assert_data_bit 




55. release_data_bit 




56. get low data byte 




57. get high data byte 




58. get_data 




jy. get_r_UKCA 




60. get PI 




61. get_atn 




62. get_reset 




63. drive_low_data_and_parity 




64. drive high data and parity 




65. drive data and parity 




66. drive_aed 




67. check_low_parity 




68. check_high_parity 




69. check_both_parity 




70. check_data_bus_for_x 




7 1 . drive_req_deskewed 




72. drive ack deskewed 




73. drive data deskewed bit 




74. drive p crca_deskewed 




75. drive_pl_deskewed 




76. drive_low_parity 




77. drive_high_parity 




78. drive_reset 




79. drive_attention 




OU. drulUdLC 




81. quick_arbitrate 


Table 4 


82. check_fairness 


Invention (SCSI 


83. get arbitration winner 
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84. get target id 




85. bsy is asserted 


oualCaUlC IVIUUUIC 


86. sel_is_asserted 


(Continued) 


87. reset_is_asserted 




88. cd_is_asserted 




89. io_is_asserted 




90. msg_is_asserted 




9 1 . atn_is_asserted 




92. req_is_asserted 




93. ack_is_asserted 




?t. t v^jrvv^/i is dsserxeu 




95. deskewed_P_CRCA_is asserted 




96. Pl_is asserted 




97. Pl_is_negated 




98. bsy is deasserted 




99. sel is deasserted 




100. atn is deasserted 




101. reset is deasserted 




102. number of data bits on 




1 03 . is phase 




104. check phase 




1 05 . set_phase 




106. force_phase 




107. get_phase 




108. target bus free 




109. initiator bus free 




HO. leselect 




ill. selection response 




112. reselection response 




sele ^ . , 




114. reset sesi bus 




115 validate aed 




116. wait for ack 




1 1 7. wait_for_not ack 




118. wait for ack posedge 




119. wait for ack negedge 




120. wait for ack deskewed posedge 




121. wait for ack deskewed negedge 


Table 4 


— — . — . — 

122. wait_lor_ack_cnange 


Invention (SCSI 


123. wait for rec] 


implementation) 


124. wait for not req 




125. wait for rec] posedge 


Shareable Nlodule 


126. wait for recj negedge 


(Continued) 


127. wait for rec| deskewed posedge 




128. wait_for req deskewed negedge 




129. wait_for_req_change 




130. wait_for_req_deskewed_change 




131. wait for sel 
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132 


wait for not scl 




133 


wait for bsy 




134. 


wait_for_not_bsy 




135. 


wait_for_bus_free 




136. 


wait_for_data 




137 


wait frtr P rRPA 

Weil i lur r v_^r\.v^/\ 




138. 


wait fnr nr\t P PT?P A 

Weil i lur not, i v^xv\_-/\ 




139. 


wait for P 1 




140. 


wait for not PI 




141. 


protocol monitor 




142. 


bus phase monitor 




143. 


enable bus phase monitor 




144. 


bus exception monitor 




145. 






146. 


bsy monitor 




147. 


sel monitor 




148. 


recj monitor 




149. 


aclc monitor 




150. 


cd monitor 




151. 






152. 


m^monitor 




153. 


at^monh'or* 




154. 


data bit monitor 




155 


data out monitor 




156. 


data in monitor 




157. 


wait_for_phase_change 




158. 


wait for recj or phase change 




159. 


wait for control change 




160. 


wait for data change 




161. 


wait for_parity change 


Table 4 


162. 


wait tor data or parity cnange 


Invention (SCSI 


163. 


wait for_any_change 


implementation) 


164 


check min timing 




165 


ch eck_m ax_t i m i n g 


Shareable Mlodule 


166. 


bus free state 


(Continued) 


167. 


reset state 




168. 


arbitration state 




169. 


qas_ar itration_state 




170 


selection state 




171 


message out state 




172 


message in state 






command state 




174 


status state 




175. 


st data in state 




176. 


st_data_out_state 




177. 


dt_data_instate 




178. 


dt_data_out_state 




179. 


spi4 dt data in state 
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180. spi4_dt_data_out_state 

181. indeterminate_state 

182. add device 

1 83 . remove_device 

1 84. add_event 

185. broadcast_event 

186. check_data_deskewed_assert 

187. check_P_CRCA_deskewed_assert 

188. check_P 1 _deskewed_assert 

1 89. check_data_P_CRCA_deskewed_assert 

1 90. check_data_P 1 _deskewed_assert 

191. check_data_P_CRC A_P 1 _deskewed_assert 

192. check data deskewed negate 

1 93 . checkJP_CRCA_deskewed_negate 

194. check_Pl_deskewed_negate 

1 95 . check_data_P_CRCA_deskewed_negate 

1 96 . check_data_P 1 _deskewed_negate 

1 97. check_data_P_CRCA_P l_deskewed_negate 

198. spi4 data in monitor 

1 99. spi4_data_out_monitor 

200. spi4_training_pattern_in_monitor 

20 1 . spi4_training_pattern_out_monitor 


Table 4 

Invention (SCSI 
implementation) 

Shareable Module 
(Continued) 


202. frc_ack_monitor 

203. frc_req_monitor 

204. wait_for_data_in_training_done 

205. wsit for dsts out training done 

206. wait for target data out training done 

207. spi_wait_for_dt_data_in 

208. spi_wait_for_dt_data_out 

209. spi get data 



Table 4: Exemplary Implementation Of Inventive Modeling Architecture For A 
SCSI-Based System Model 

5 

As mentioned earlier, the shareable module also includes logic functions that 
allow the shareable module to perform a logic function on behalf of multiple device 
models. Take for example the previously discussed function of selecting a device for 
communication. In the prior art, since each device model attempts to faithfully mimic 
10 the real-world capability of its respective real-world device, each device model 

typically monitors for the "BUSY" and "SELECT" signals, as well as the device ID 
asserted on the shared bus. When there are multiple devices coupled to the shared 



ATECP001/SSG-054A 



36 



PATENT 



bus, as is usually the case, multiple of these logic functions execute simultaneously on 
behalf of their respective device models. 

In accordance with one embodiment of the present invention, such a logic 
function, i.e., a logic function that can be performed on behalf of multiple device 
5 models, is preferably provisioned in the shareable module and executed on behalf of 
the multiple device models. For example, the logic function of monitoring for the 
"BUSY" and "SELECT" signals, as well as the device ID asserted on the shared bus 
can be performed by codes in the shareable module on behalf of the device models. 
Once codes in the shareable module determines that a given device identified by the 

1 0 asserted device ID has been selected by another device, it can simply notify the device 
being selected to enable the selected device to respond to the device making the 
request. Other analogous functions, including, for example, data transfer, reset, error 
detection, and the like, may also be provisioned in the shareable module and executed 
by the shareable module on behalf of the multiple device models. In this manner, the 

15 invention advantageously reduces the processing load on the CPU, leading to 
improved performance in terms of speed and memory usage for the modeling 
software. 

While this invention has been described in terms of several preferred 
embodiments, there are alterations, permutations, and equivalents which fall within 
20 the scope of this invention. It should also be noted that there are many alternative 
ways of implementing the methods and apparatuses of the present invention. It is 
therefore intended that the following appended claims be interpreted as including all 
such alterations, permutations, and equivalents as fall within the true spirit and scope 
of the present invention. 

25 
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